Network Working Group G. Ziemba 


Request for Comments: 1858 Alantec 
Category: Informational D. Reed 
Cybersource 


P. Traina 
cisco Systems 
October 1995 


Security Considerations for IP Fragment Filtering 
Status of This Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


IP fragmentation can be used to disguise TCP packets from IP filters 
used in routers and hosts. This document describes two methods of 
attack as well as remedies to prevent them. 


1. Background 


System administrators rely on manufacturers of networking equipment 
to provide them with packet filters; these filters are used for 
keeping attackers from accessing private systems and information, 
while permitting friendly agents to transfer data between private 
nets and the Internet. For this reason, it is important for network 
equipment vendors to anticipate possible attacks against their 
equipment and to implement robust mechanisms to deflect such attacks. 


The growth of the global Internet has brought with it an increase in 
"undesirable elements" manifested in antisocial behavior. Recent 
months have seen the use of novel attacks on Internet hosts, which 
have in some cases led to the compromise of sensitive data. 


Increasingly sophisticated attackers have begun to exploit the more 
subtle aspects of the Internet Protocol; fragmentation of IP packets, 
an important feature in heterogeneous internetworks, poses several 
potential problems which we explore here. 
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Filtering IP Fragments 


IP packet filters on routers are designed with a user interface that 
hides packet fragmentation from the administrator; conceptually, an 
IP filter is applied to each IP packet as a complete entity. 


One approach to fragment filtering, described by Mogul [1], involves 
keeping track of the results of applying filter rules to the first 
fragment (FO==0) and applying them to subsequent fragments of the 
same packet. The filtering module would maintain a list of packets 
indexed by the source address, destination address, protocol, and IP 
ID. When the initial (FO==0) fragment is seen, if the MF bit is set, 
a list item would be allocated to hold the result of filter access 
checks. When packets with a non-zero FO come in, look up the list 
element with a matching SA/DA/PROT/ID and apply the stored result 
(pass or block). When a fragment with a zero MF bit is seen, free 
the list element. 


Although this method (or some refinement of it) might successfully 
remove any trace of the offending whole packet, it has some 
difficulties. Fragments that arrive out of order, possibly because 
they traveled over different paths, violate one of the design 
assumptions, and undesired fragments can leak through as a result. 
Furthermore, if the filtering router lies on one of several parallel 
paths, the filtering module will not see every fragment and cannot 
guarantee complete fragment filtering in the case of packets that 
should be dropped. 


Fortunately, we do not need to remove all fragments of an offending 
packet. Since "interesting" packet information is contained in the 
headers at the beginning, filters are generally applied only to the 
first fragment. Non-first fragments are passed without filtering, 
because it will be impossible for the destination host to complete 
reassembly of the packet if the first fragment is missing, and 
therefore the entire packet will be discarded. 


The Internet Protocol allows fragmentation of packets into pieces so 
small as to be impractical because of data and computational 
overhead. Attackers can sometimes exploit typical filter behavior 
and the ability to create peculiar fragment sequences in order to 
sneak otherwise disallowed packets past the filter. In normal 
practice, such pathalogical fragmentation is never used, so it is 
safe to drop these fragments without danger of preventing normal 
operation. 
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3. Tiny Fragment Attack 


With many IP implementations it is possible to impose an unusually 
small fragment size on outgoing packets. If the fragment size is 
made small enough to force some of a TCP packet’s TCP header fields 
into the second fragment, filter rules that specify patterns for 
those fields will not match. If the filtering implementation does 
not enforce a minimum fragment size, a disallowed packet might be 
passed because it didn’t hit a match in the filter. 


STD 5, RFC 791 states: 


Every internet module must be able to forward a datagram of 68 
octets without further fragmentation. This is because an internet 
header may be up to 60 octets, and the minimum fragment is 8 
octets. 


Note that, for the purpose of security, it is not sufficient to 
merely guarantee that a fragment contains at least 8 octets of data 
beyond the IP header because important transport header information 
(e.g., the CODE field of the TCP header) might be beyond the 8th data 
octet. 


3.1 Example of the Tiny Fragment Attack 


In this example, the first fragment contains only eight octets of 
data (the minimum fragment size). In the case of TCP, this is 
sufficient to contain the source and destination port numbers, but 
it will force the TCP flags field into the second fragment. 


Filters that attempt to drop connection requests (TCP datagrams 
having SYN=1 and ACK=0) will be unable to test these flags in the 
first octet, and will typically ignore them in subsequent 


fragments. 

FRAGMENT 1 

IP HEADER 

十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 

| Fragment Offset = 0 | 

二 二 于 三 下 于 二 十 守 丰 三 证 二 中 二 让 二 于 三 下 二 下 二 站 二 二 三 让 二 太 tettet 

TCP HEADER 

Fatt ata ta tata tartar t arta tantantatata tt tata t ata tatatatatatatatatatat 
| Source Port | Destination Port | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Sequence Number | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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FRAGMENT 2 

IP HEADER 

十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 
| Fragment Offset = 1 aie 

十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 

TCP HEADER 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Acknowledgment Number | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| Data | |u|A|P|R|S|F| | 
| Offset| Reserved |R|c|s|s|y|TI| Window 

| |G|K|H|T|N|N| | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


3.2 Prevention of the Tiny Fragment Attack 


In a router, one can prevent this sort of attack by enforcing 
certain limits on fragments passing through, namely, that the 
first fragment be large enough to contain all the necessary header 
information. 


There are two ways to guarantee that the first fragment of a 
"passed" packet includes all the required fields, one direct, the 
other indirect. 


3.2.1 Direct Method 


There is some number TMIN which is the minimum length of a 
transport header required to contain "interesting" fields 
(i.e., fields whose values are significant to packet filters). 
This length is measured from the beginning of the transport 
header in the original unfragmented IP packet. 


Note that TMIN is a function of the transport protocol involved 
and also of the particular filters currently configured. 


The direct method involves computing the length of the 
transport header in each zero-offset fragment and comparing it 
against TMIN. If the transport header length is less than 
TMIN, the fragment is discarded. Non-zero-offset fragments 
need not be checked because if the zero-offset fragment is 
discarded, the destination host will be unable to complete 
reassembly. So far we have: 
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if FO=0 and TRANSPORTLEN < tmin then 
DROP PACKET 


However, the "interesting" fields of the common transport 
protocols, except TCP, lie in the first eight octets of the 
transport header, so it isn’t possible to push them into a 
non-zero-offset fragment. Therefore, as of this writing, only 
TCP packets are vulnerable to tiny-fragment attacks and the 
test need not be applied to IP packets carrying other transport 
protocols. A better version of the tiny fragment test might 
therefore be: 


if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then 
DROP PACKET 


As discussed in the section on overlapping fragments below, 
however, this test does not block all fragmentation attacks, 
and is in fact unnecessary when a more general technique is 
used. 


3.2.2 Indirect Method 


The indirect method relies on the observation that when a TCP 
packet is fragmented so as to force "interesting" header fields 
out of the zero-offset fragment, there must exist a fragment 
with FO equal to 1. 


If a packet with FO==1 is seen, conversely, it could indicate 
the presence, in the fragment set, of a zero-offset fragment 
with a transport header length of eight octets Discarding this 
one-offset fragment will block reassembly at the receiving host 
and be as effective as the direct method described above. 


4. Overlapping Fragment Attack 


RFC 791, the current IP protocol specification, describes a 
reassembly algorithm that results in new fragments overwriting any 
overlapped portions of previously-received fragments. 


Given such a reassembly implementation, an attacker could construct a 
series of packets in which the lowest (zero-offset) fragment would 
contain innocuous data (and thereby be passed by administrative 
packet filters), and in which some subsequent packet having a non- 
zero offset would overlap TCP header information (destination port, 
for instance) and cause it to be modified. The second packet would 
be passed through most filter implementations because it does not 
have a zero fragment offset. 


Ziemba, Reed & Traina Informational [Page 5] 


RFC 1858 Security Considerations - IP Fragment Filtering October 1995 


RFC 815 outlines an improved datagram reassembly algorithm, but it 
concerns itself primarily with filling gaps during the reassembly 
process. This RFC remains mute on the issue of overlapping 
fragments. 


Thus, fully-compliant IP implementations are not guaranteed to be 
immune to overlapping-fragment attacks. The 4.3 BSD reassembly 
implementation takes care to avoid these attacks by forcing data from 
lower-offset fragments to take precedence over data from higher- 


offset fragments. However, not all IP implementations are based on 
the original BSD code, and it is likely that some of them are 
vulnerable. 


4.1 Example of the Overlapping Fragment Attack 


In this example, fragments are large enough to satisfy the minimum 
size requirements described in the previous section. The filter 
is configured to drop TCP connection request packets. 


The first fragment contains values, e.g., SYN=0, ACK=1, that 
enable it to pass through the filter unharmed. 


The second fragment, with a fragment offset of eight octets, 
contains TCP Flags that differ from those given in the first 
fragment, e.g., SYN=1, ACK=0. Since this second fragment is not a 
O-offset fragment, it will not be checked, and it, too will pass 
through the filter. 


The receiving host, if it conforms fully to the algorithms given 


in RFC 791, will reconstitute the packet as a connection request 
because the "bad" data arrived later. 
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FRAGMENT 1 

IP HEADER 

tepri e U Sae E E E e a E 再 二 于 二 下 = 站 

Beate Fragment Offset = 0 | ... 

再 一 十 二 二 十 EE iai an DOR S Sa E G ds Foppa 

TCP HEADER 
机 
| Source Port Destination Port | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Sequence Number | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Acknowledgment Number | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Data UIAIPIRISIF 
Offset| Reserved RICISISIYII Window 

| | IG|K/H|T|N]N| | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
(Other data) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


FRAGMENT 2 

IP HEADER 

tot-t+—-+ 二 二 中 三 六 一半 汪 十 二 十 二 二 二 证 二 十 二 二 二 于 = 下 十 二 站 三 十 二 二 
... | Fragment Offset = 1 ee 

=r 二 于 二 十 三 下 二 于 二 于 三 上 三 二 二 于 关于 二 二 三 二 十 一 十 一 十 一 十 

TCP HEADER 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Acknowledgment Number 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Data | |u|A|P|R|S|F| 
Offset] Reserved RICISISIYII 
G|K|H|T|N|N 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Window 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
(Other data) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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If the receiving host has a reassembly algorithm that prevents new 
data from overwriting data received previously, we can send 
Fragment 2 first, followed by Fragment 1, and accomplish the same 
successful attack. 


4.2 Prevention of the Overlapping Fragment Attack 


Since no standard requires that an overlap-safe reassembly 
algorithm be used, the potential vulnerability of hosts to this 
attack is quite large. 


By adopting a better strategy in a router’s IP filtering code, one 
can be assured of blocking this "attack". If the router’s 
filtering module enforces a minimum fragment offset for fragments 
that have non-zero offsets, it can prevent overlaps in filter 
parameter regions of the transport headers. 


In the case of TCP, this minimum is sixteen octets, to ensure that 
the TCP flags field is never contained in a non-zero-offset 
fragment. If a TCP fragment has FO==1, it should be discarded 
because it starts only eight octets into the transport header. 
Conveniently, dropping FO==1 fragments also protects against the 
tiny fragment attack, as discussed earlier. 


RFC 791 demands that an IP stack must be capable of passing an 8 
byte IP data payload without further fragmentation (fragments sit 
on 8 byte boundaries). Since an IP header can be up to 60 bytes 
long (including options), this means that the minimum MTU on a 
link should be 68 bytes. 


A typical IP header is only 20 bytes long and can therefore carry 
48 bytes of data. No one in the real world should EVER be 
generating a TCP packet with FO=1, as it would require both that a 
previous system fragmenting IP data down to the 8 byte minimum and 
a 60 byte IP header. 


A general algorithm, then, for ensuring that filters work in the 
face of both the tiny fragment attack and the overlapping fragment 
attack is: 


IF FO=1 and PROTOCOL=TCP then 
DROP PACKET 


If filtering based on fields in other transport protocol headers 
is provided in a router, the minimum could be greater, depending 
on the position of those fields in the header. In particular, if 
filtering is permitted on data beyond the sixteenth octet of the 
transport header, either because of a flexible user interface or 
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the implementation of filters for some new transport protocol, 
dropping packets with FO==1 might not be sufficient. 


5. Security Considerations 


This memo is concerned entirely with the security implications of 
filtering fragmented IP packets. 
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